The UPnP (Universal Plug and Play) architecture provides network connectivity of consumer electronics devices such as appliances, wireless devices, electronics, portable media devices and personal computers. UPnP is a distributed, open networking architecture that leverages TCP/IP and the Web technologies to enable proximity networking and control data transfer among networked devices in the home, office, and public spaces. UPnP is designed to support zero-configuration, “invisible” networking, and automatic discovery for a breadth of device categories from a wide range of vendors. Devices can dynamically join a network, obtain an IP address, convey its capabilities, and learn about the presence and capabilities of other devices. Also, a UPnP device can leave a network without leaving any unwanted state behind.
In the UPnP model, all devices are assumed to be implicitly authorized to make any possible request to enable the so-called “invisible” networking. Without authentication, however, a device that receives a UPnP request from another UPnP device does not know if the device sending the request is authorized to make such requests. Because UPnP was designed for home networks and the like in which all devices are assumed to be trusted, the authentication and authorization of devices was not necessary. However, even within home networks, the lack of support for authorization and authentication in UPnP can be problematic. For example, suppose the shared network is implemented in a college dormitory or in an environment utilizing wireless technology (e.g., Wi-Fi). In such cases, an owner of a UPnP-based file server may not want to grant unrestricted access to the files that are stored on a server of the network because the owner may not be able to trust all other UPnP devices capable of accessing the network.
In another example, suppose the manufacturer of a UPnP-based media server capable of streaming high-definition video may wish to limit the access to the high-definition video content to devices that are licensed and capable of rendering the high-definition video content while streaming a standard-definition version of the video content to other devices. In other words, the manufacturer of UPnP devices may wish to permit access to a subset of UPnP devices, such as those made by the same manufacturer.
Existing solutions to the authentication and authorization problems are either incomplete, not sufficiently secure, or tied to a Digital Rights Management (DRM) system. For example, a common solution to the authentication problem is to look for a well-known human readable string in one or more of the UPnP messages. The string can be in the User-Agent protocol header or it can be embedded in the device description document, an XML-format document that can be downloaded from all UPnP devices. A first UPnP device that wants to authenticate a second UPnP device checks for the presence of one of these strings. If found, the first UPnP device would consider the second UPnP device to be authenticated. However, this solution is not secure because the strings are transmitted in a clear human readable form which is trivial to replicate.
In another existing solution, the UPnP device receiving the request looks up the Ethernet MAC (Media Access Control) address of a UPnP request in a table of addresses of authorized devices. If the MAC address of the requesting device is found, the device is considered to be authorized. Otherwise, the user of the receiving device is given the option of granting access to the requesting device and adding its address to the table. However, this solution is not secure because Ethernet MAC addresses are relatively easy to “spoof” or forge.
Furthermore, the solution is impractical in the scenario where a UPnP device wants to restrict access to only certain licensed or approved devices. Because Ethernet MAC addresses are usually stored in a hardware chip that is manufactured separately from the UPnP software. It is usually impractical for the software manufacturer to create a table of authorized Ethernet MAC addresses because the MAC addresses of the approved devices are not known at the time the software is created. Additionally, in this scenario, it is not desirable to prompt the user to add the MAC address to the table of authorized MAC addresses because the user may grant access to an unlicensed or unapproved device.
A third solution is provided by conventional DRM systems. Although a DRM system allows two devices to authenticate each other and to transfer audio/video content in encrypted form, this very specialized solution is not applicable in all scenarios. For example, it may not always be desirable to encrypt the content that is being transferred as is required by DRM systems. Also, some DRM systems have a secure (encryption-based) message exchange during the transfer audio/video content, but the discovery of the content (through the UPnP ContentDirectory service) is not covered by this secure message exchange. Thus, a first device may discover content in the ContentDirectory service of a second device without knowing if the first device is authorized to stream the discovered content.